Currently the attestation flow only works against the mock attestation
server. Against the production-ready Trustee KBS (CoCo), attestation
fails immediately because the cryptographic hashes do not match.

The RCAR (Request-Challenge-Attestation-Response) handshake forms the
basis of secret retrieval from KBS. This has 2 parts, negotiation and
attestation. Negotiation phase typically only allows the client to get a
nonce from the KBS, and this nonce will be used in the attestation
request in the subsequent step. For SVSM, the client is SVSM + aproxy.

The current negotiation request:
  SVSM sends only version and tee to aproxy. SVSM public key is not sent.
The current negotiation response:
  aproxy fetches the challenge nonce from KBS and send it back to SVSM.
The current hashing in svsm:
  SVSM does the hashing locally in the kernel by concatenating the raw
bytes of the nonce and the pub_key coordinates, hashing them with
SHA-512.

Report data = sha512(nonce + pub_key_x + pub_key_y).
This is signed by the AMD processor.

The real Trustee KBS does not expect a raw concatenation of bytes hashed
with SHA-512. Instead, the KBS verifier expects the runtime data to be a
JWS-formatted JSON object containing specific parameters, hashed with
SHA-384, see below.

{
  "nonce": kbs-nonce,
  "additional-evidence": "",
  "tee-pubkey": {
    "kty": "EC",
    "crv": "P-521",
    "x": "..."
    "y": "..."
  }
}

Although the hashing and serializing can be done in SVSM, it is not wise
to add/implement the JSON serializer in the kernel. We would also
require a base64url encoder. Besides, if SVSM constructs the
KBS-specific JSON, SVSM becomes tightly coupled to the specific API
implementation of a single KBS (Trustee).

For those reasons, the job of serialising and hashing should be done by
the aproxy. Because the baremetal SVSM kernel cannot do complex JSON
formatting, serialization, JWS mapping and base64 encoding, SVSM could
not compute this JSON-based hash. As a result the hash SVSM signed in the report
never matches the hash that KBS expected, and the attestation failed.

This commit allows aproxy to have the public key of svsm ready to use
during the negotiation phase itself. By sending SVSM's public key during
negotiation, aproxy can compute the SHA-384 of the constructed JSON first,
and pass it back to SVSM. SVSM can pass that hash to the AMD CPU to be
hardware-signed.

SVSM              APROXY        Trustee KBS
  |                 |                |
  |                 |                |
  | 1. Negotiation  |                |
  +---------------->|                |
  |    Request      |                |
  |(tee, ver, pk)   |2. GET/auth     |
  |                 +--------------->|
  |                 | 3. Returns     |
  |                 |<---------------+
  |                 | challenge nonce|
  |                 |                |
  |                 |                |
  |                 |                |
  |                 |4. Precomputes  |
  |                 |   KBS hashing. |
  |                 |a. Constructs runtime_data JSON
  |                 |  (with nonce + SVSM key)
  |                 |b. Computes sha-384 of this JSON
  |                 |   This is called challenge hash
  |                 |                |
  |                 |                |
  |                 |                |
  |  5. Negotiation |                |
  |<----------------+                |
  |     Response    |                |
  |                 |                |
  |                 |                |
  |                 |                |
  |6. Requests Hardware Report       |
  |   Passes Challenge hash as       |
  |   REPORT_DATA. AMD CPU signs     |
  |   Challenge Hash|                |
  |                 |                |
  |                 |                |
  |                 |                |
  |                 |                |
  |  7. Attestation |                |
  +---------------->|                |
  |     Request     |                |
  | Sends TEE report|                |
  | + SVSM pubkey   |                |
  |                 | 8. POST/attest |
  |                 +--------------->|
  |                 | -Sends TEE rep |
  |                 | -Sends runtime_|
  |                 |  data JSON with|
  |                 | (nonce + pubkey)
  |                 |                |
  |                 |                |
  |                 |                | 9.Verification at KBS
  |                 |                |  a. Compute sha384 of runtime
  |                 |                |     data (covers nonce+pubkey)
  |                 |                |  b. Reads REPORT_DATA from TEE
  |                 |                |     Report. Contains (challenge Hash)
  |                 |                |  c. Compares both. Attestation
  |                 |                |     accepted. Issue attestation token.
  v                 v                v

A subsequent commit will move the JSON construction and hashing
responsibility out of the kernel, and put it into the aproxy.

Signed-off-by: Arun Menon <armenon@redhat.com>